【レポート】アドテクのビッグデータを制するSnowflakeの力 – Snowflake Data Cloud World Tour Tokyo #SnowflakeDB

【レポート】アドテクのビッグデータを制するSnowflakeの力 – Snowflake Data Cloud World Tour Tokyo #SnowflakeDB

Clock Icon2023.09.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、スズです。

2023年09月08日(金)、ANAインターコンチネンタル東京にて、Snowflake社による日本最大級のデータイベント「Snowflake Data Cloud World Tour Tokyo」が開催されました。

本記事では、『アドテクのビッグデータを制するSnowflakeの力』のセッションレポートをお届けします。

セッション概要

  • スピーカー
    • 株式会社CARTA HOLDINGS Zucks システム局 エンジニア 近森 淳平 氏

このセッションでは、Snowflakeがどのようにして、アドテクで発生する多種多様なビッグデータの一元管理を可能にし、データの真の価値を引き出す方法について詳しく説明します。データサイロの解消から多様なワークロードへの対応、Snowflakeがどのように運用上の課題を解決可能にし、ビジネス価値を引き立てるのかを、具体的な事例と共に解説します。
このセッションを通じて、Snowflakeの優れた特性を理解し、ビッグデータをより効果的に活用するための新たな視野を開くことを目指します。

引用元:Data Cloud World Tour - Tokyo - Agenda

セッション内容

アドテクってどんな世界?

  • アドテクは毎年猛烈な変化を遂げ、大量にデータを生み出す
    • データ活用に対する需要が現場で膨れ上がってくる
  • データ基盤が需要に応えられる状況ではなく、疲弊をしていた
    • データを見るだけで日々疲弊していく
  • Snowflakeを導入したことでデータ業務が根本的に変わった

アドテクとデータの関係性

  • アドテクにおけるデータとは
    • アドテクは業務のほとんどがソフトウェア上で完結している
    • アドテクにおけるデータは業務活動そのもの

  • アドテクはどのようなデータなのか
    • 大量の半構造化データ
    • 1つのログだけで億レコード単位が日々発生する
  • 広告はオークションしている
    • 大きいJSONのデータでやり取りしている
  • データが中心のビジネスであるため、データをコントロールすることは重要

現場のデータ課題

  • Zucksのアドテク事業は大きく3つ
    • アドネットワーク、デマンドサイドプラットフォーム、アフィリエイト

  • 大きく分けて、レポーティング、分析 + 機械学習、プロダクトといった業務がある
    • それぞれの業務に応じて、Amazon Redshift、Amazon Aurora、Google BigQueryを使用している

  • ざっくりとしたアーキテクチャ
    • それぞれのAWSのアカウントがあり、それぞれにデータストアがある

  • この現場では、データ利活用が大変
    • データのサイロ化が起きていた
      • データのサイロ化が起きると、利活用のオーバーヘッドを高くする
  • ケーススタディ:色々なデータにクエリして金脈を探す
    • 負荷レベル松:分析基盤にあるデータにクエリする
      • データアナリストが分析基盤に一発クエリして終わり

  • 負荷レベル竹:分析基盤にあるデータと、特定プロダクトのレポーティングデータにクエリする
    • データアナリストはまず分析基盤にクエリする
    • レポーティングにしかないデータがあるため、レポーティングにもクエリする
    • それぞれのデータは突合できないため、ローカルPCでジョインしようとする
      • アドテクのデータをローカルPCで行うのは大変

  • 負荷レベル梅:分析基盤にあるデータと、レポーティングとアプリDBのデータを見る
    • まず分析基盤にクエリ
    • アプリのデータは踏み台に入らないとデータが取れない

  • データを取ってくるだけで大変、利活用の障壁になっている
  • 取ってきたデータもカオス
  • データをそろえるところで9割、本質的な仕事がたったの1割
  • 苦労して取ってきたデータが使えないということが続くと、人々は疲れてしまう
    • データ利活用をやらなくなってしまう

  • データ利活用の前のプロダクト横断したレポーティングといった普段の業務でさえ大変
  • まずはレポーティング業務を整理することろから始めた

  • データがサイロ化していると、構造的に生産性を上げられない
  • サービスがスケールするほどクエリする場所が増える
  • データが一箇所にある状態を作るという話になる
    • そこで選択したのがSnowflake

なぜSnowflakeなのか?

  • 既存のデータ基盤ではうまくやれないのか?
    • 既存の基盤を置き換えてもSnowflakeの方が優位性があったという結論になった
  • BigQueryの場合の転送コスト
    • 自社サービスがAWS上で動いている
      • ログがAmazon S3に集約されている
    • BigQueryで利用するにはまずデータの転送が必要
  • Snowflakeは好きなクラウドサービスを選んで展開できる
    • AWSにあるログを動かさずに利用できる
    • ロードする作業もSnowflakeにお任せできる
    • コストを削減できる

  • チューニング余地について
    • クエリによってやりたいことが違う
      • 結果を高速に返すことを優先したい、コストを下げることを優先したい
    • 細かくニーズに対応できるのがSnowflake
      • チューニングして安くする余地がある

  • Redshiftの場合のコンピューティング管理
    • Redshiftの場合パフォーマンス上限がクラスターに依存する
    • Snowflakeでは権限を割り当てて、このデータはこのウェアハウスでクエリしてください、で対応できる

  • どうやって稼働中の既存のワークロードを移行するのか
    • 一部だけ移行するとまた新しいサイロができてしまうので、全部移行するいきおいでやっている
  • Redshiftのレポーティング基盤の移行は完了
    • dbtを使ってレポーティングを実現していた
      • RedshiftモードだったものをSnowflakeモードに切り替えた
      • クエリ資産をそのままSnowflakeで利用できる
    • 切り替え日だけ決めてうまくやるという戦略
      • 昨日までのデータはRedshiftを使い、今日からのデータはSnowflakeを使う

  • ほとんどこのパターンで対応できる
  • RedshiftからAmazon S3にデータをUnloadし、SnowflakeからExternal Tableで読み込む
  • 新しいログはSnowpipeを使う
  • レポーティング業務している人はSnowflakeにクエリするだけ

  • BigQuery分析基盤の移行は、全部移行するのがきつかった
    • 新しい分析業務はSnowflakeでできるようにし、古いものと新しいもので分ける
  • Snowflake上でデータを作り、Google Cloud StorageにUnloadし、BigQueryでクエリする
    • BigQueryベースで動いているバッチをそのまま利用できる

  • アーキテクチャは以下の図の通り
    • Amazon S3のログをSnowpipeでSnowflakeにロード
    • BigQueryと同じロジックで集計し、Google Cloud StorageにUnload
    • BigQueryはExternal Tableでクエリする
  • 計算済みのデータしかないので、以前よりコストが下がる

  • あとはSnowflakeベースの基盤を作って終わり
    • この点は過去に発表しているので見てほしい

1年間の振り返りと得られた利点

  • 導入して1年経過、お世辞抜きに最高
    • 大体Snowpipeで解決する
  • 良い点を1つに絞ると、運用がとても楽
    • 少ない手間で多くのことを成し遂げられる
    • Snowflakeの基盤を作った時はほとんど1人で作った
  • Snowflakeの運用が楽な理由は主に4つ

高い安定性

  • この1年間、Snowflakeによる障害が一切ない

  • データを使って価値を出しているため、データ基盤が止まると価値が止まる
  • Snowflakeが安定していることは、我々の価値の提供も安定していることになる

  • Snowflakeのアーキテクチャは、良い意味で枯れた技術を使っている
    • もし障害が起きたとしたらこういうことが起こるという手触り感がある

ウェアハウスが、とにかく便利

  • レポーティング、分析、機械学習で求められることに応じて、適切にウェアハウスを割り当てられる

  • 適切なサイズの割り当てが簡単
    • ワークロード的に30秒かかっても安い方がいい場合はそちらを選ぶ
    • とりあえずLargedを割り当てて、Mediumに変更したい場合もダウンタイムが発生しない

質の高いサポート体制

  • びっくりするくらい欲しい答えが返ってくる
    • 困ってることに対して、使わせたいものではなく、使った方がいいものを提案してくれる
      • 本質的な答えを返してくれる
  • ドキュメントが分かりやすい
    • ちょっとドキュメントが読みにくいことがあってサポートに言うと、すぐに直る

日本のコミュニティが活発

  • 初学者から上級者まで楽しめる工夫がされている

  • 運用とコミュニティの関係
    • 活発なコミュニティは価値が出る場所が1箇所じゃない
  • 日本語で読める情報が増える -> 新しいユーザーが増える
    • 色々な人がいるから、色々な知見が共有される、色々な機能が出てくる
    • 結果として日本が重要な市場だから投資しようとなり、最終的に我々のビジネス加速の源泉になると思っている

まとめ

  • 運用が大変だと本質的な仕事に取り掛かれない
  • 運用が本当に楽なので、ここに乗っかることであとは腕前でどうにかなる

最後に

Snowflake Data Cloud World Tour Tokyoでのセッション『アドテクのビッグデータを制するSnowflakeの力』のレポートをお届けしました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.